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(57) Abstract 

The present invention provides a network system for 
storage of medical records. The records are stored in a database 
on a server. Each record includes two main parts, namely a 
collection of data elements containing information of medical 
nature for a certain individual, and a plurality of pointers 
providing addresses or remote locations where reside other 
medical data for that particular individual. Each record also 
includes a data element indicative of the basic type of medical 
data found at the location pointed to by a particular pointer. 
This arrangement permits a client workstation to download the 
record along with the set of pointers which link the client to 
the remotely stored files. The identification of the basic type of 
information that each pointer points to allows the physician to 
select the ones of interest and thus avoids downloading massive 
amounts of data where only part of that data is needed at that 
time. In addition, this record structure allows statistical queries 
to be effected without the necessity of accessing the data behind 
the pointers. For instance, a query can be built based on keys, 
one of which is the type of data that a pointer points to. The 
query can thus be performed solely on the basis of the pointers 
and the remaining information held in the record. 
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Field of the Invention 

The present invention relates to the field of information 
5 distribution systems. More specifically, it pertains to a device 
and method for the electronic management of data files, for 
instance within the medical and health education domains. 



Background of the Invention 

10 The following paragraphs give definitions of terms relevant 

to this document: 

Client-Server: Client-server computing implies that a single 
application is being jointly accomplished by two or more 
interdependent pieces of equipment, including software, hardware 

15 and interface. The client requests information and the server 
provides it, with each one assigned the portion of the job which 
is suitable to its capabilities. Client-server can be achieved in 
a local area network of personal computers and servers or by means 
of a link between a user system and a large host such as a 

20 mainframe. Typically, a client-server environment implies a many 
to one design, whereby multiple clients can make simultaneous 
requests of the server, allowing for server information sharing 
between clients. A crucial aspect of Internet Protocol (IP) based 
technology, such as the World Wide Web (WWW) , is the fact that it 

25 is a client-server application. 

Intranet: An intranet is any internal network (LAN or WAN) 
that supports Internet applications - primarily web (hypertext 
transfer protocol) , but also other applications such as FTP (file 
transfer protocol) . Intranets are used by many companies to 
30 deliver private corporate information to internal users. 

Local vs. Wide Area Network: A local area network (LAN) is 
a private internal communication network that is confined to a 
small area, such as a single building or a small cluster of 
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buildings. It is a general -purpose local network that cari^-serve ' 
a variety of devices, and is generally owned, used, and operated 
by a single organization. A wide area network (WAN) is similar to 
a LAN in that it is also a communication network, but a WAN extends 
5 over a much broader area, interconnecting communication facilities 
in different parts of a country. A WAN may also be used as a 
public utility. 

Open Systems A system with the capability to cooperate with 
another system in the exchange of information and in the 
10 accomplishment of tasks, where the two systems may be implemented 
very differently. Every open system must conform to a minimal set 
of communication and protocol standards, as defined by the open- 
systems interconnection (OSI) model. 

Standard Exchange Protocols: A protocol is the set of rules 
15 or conventions governing the way in which two entities cooperate 
to exchange data. An example of such a protocol is the Internet 
Protocol (IP), a library of routines called on by various network 
communications applications . 

In the past few years, the worlds of information and 
20 technology have made important evolutions. We have progressed from 
a universal analogical support, usually on paper, towards a 
theoretically universal electronic support based on the multimedia 
as well as Internet Protocol (IP) based technology such as the 
World Wide Web (WWW) , JAVA and ICQ (I Seek You) . The transmission 
25 of information has also made tremendous progress and is already, 
or will be soon, practically instantaneous no matter the form of 
information: text, data, sound, fixed or animated image. 

Th e search for information is becoming more and more similar 
to the concept of navigation among diverse sources of information 
30 and even within documents themselves. The concept of navigation 
itself implies the need for user accessible tools as well as some 
sort of structured organization. 

Narrowing the focus, this major revolution of information 
systems brings about profound changes in the relations between 
35 academic and hospital domains, in particular everything which deals 
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with medical archives and databases as well as the ability to 
consult aggregates of these in a transparent way and to share in 
real or delayed time the information obtained. The number of 
information sources is multiplying and the communication networks 
are proliferating: more and more documentation is available in 
digital form and the information highway is rapidly expanding. 
Concerning medical archives and databases, questions arise as to 
their role of maintaining or distributing information/ If their 
roles of acquiring, cataloging and maintaining information are to 
continue, they will have to give access to the available 
information on new multimedia supports as well as serve as access 
points to the information within enlarged networks (e.g. the 
healthcare inforoute) . These changes will add to the complexity 
of their management, all the while enlarging their traditional 
mandate . 

In other words, the medical archives and databases of the 
future will not only be locally archived medical-legal clinical 
documents, but also high-performance data banks of primary 
importance to the practice of medicine and health care everywhere 
within our network, all the while constituting a living core 
dedicated to clinical and scientific research and development. 

The above described evolution of the medical file and database 
system requires that the following two objectives be achieved: 

effective navigation across multiple and diverse sources of 
information, both local and distant, performed in a 
transparent way with respect to the end user; 
♦ efficient file management allowing universal research, the 

treatment of contained information, and the sharing of 
information between system users. 

Currently, in order to store medical archives and databases, 
passive data accumulation for each medical facility takes place 
within a local network. Unfortunately, the costs of stocking 
information and storing files in a local network are quite high and 
the space available is limited. There is also a well established 
historical insufficiency concerning the ability of the local 
medical archive file networks to respond to the documentary and 
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informational needs of the emergency doctor or of the consultant. 
The medical facilities do not have access to a complete ensemble 
of information sources, thus complicating emergency medical 
procedures and diagnoses all the while hampering the facility's 
ability to give patients the most appropriate treatment. 

Although the solution of combining the multiple independent 
local networks into a single integrated health network seems rather 
obvious, the implementation of such a concept presents certain 
problems concerning the manner in which medical data is currently 
recorded and treated, at both text and image levels. First of all, 
each separate medical facility may count up to hundreds of 
thousands of active files, some archived locally, others 
externally, either in an integrated or a refined form. Second of 
all the file organization may be different at each facility, a huge 
obstacle to the merging of all files into a system which supports 
a common format file organization. There is also the problem of 
available space when considering the large volume of information 
contained in each file and the fact that the life of a particular 
medical file may approach up to twenty-five years in length. Thus 
volume and merging problems lead to the conclusion that it is 
currently almost impossible to combine and digitize the whole of 
all local medical records from all local networks. 

Even if the merging and digitizing were possible, there is a 
question as to whether this would be desired. The data recorded 
in the medical files does not all have the same informational and 
discriminatory value in the long run. In fact, the data falls into 
three categories: data with strict medical-legal value, data with 
short term clinical value and data with historical value or a 
biological signature. Unfortunately, the first category, data with 
strict medical-legal value, makes up the majority of data recorded 
in the file while it represents the least valuable information for 
emergency doctors and consultants. On the other hand, the most 
valuable information for emergency procedures and diagnoses, the 
third category, makes up a very small portion of data recorded in 
the file. Therefore an integrated file management system which 
combines all of the information currently held in archived medical 
files would be extremely inefficient in terms of usage of space, 
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thus impairing the extraction of information pertinent to a 
particular research. 

The background information herein clearly shows that there 
exists a need in the industry to provide a method for developing 
the information highway to allow for access to shared medical files 
in an enlarged health network and other external databases in order 
to increase the number of available sources of information for 
doctors and consultants. 

Objectives and summary of the invention 

An object of the present invention is to provide a system and 
method for electronic management of data files. 

Another object of the invention is a computer readable storage 
medium containing a data structure that holds information. 

As embodied and broadly described herein, the invention 
provides a computer readable storage medium holding a data 
structure, said data structure comprising at least one record 
associated with a certain individual, said record including: 

- at least one unique identifier associated strictly with the 
certain individual ; 

- at least one pointer, said pointer using the URL addressing 
system to indicate the address of a location containing data for 
the certain individual, said address being in a form such that a 
machine can access the location and import the data from the 
location; 

- at least one data field, said data field associated with 
said pointer, said data field being indicative of the basic nature 
of the data at the location pointed to by the said pointer. 

In a preferred embodiment, the computer readable storage 
medium is a database containing a large number of medical records 
"for respective individuals. The information in each record 
includes at least one attributed identifier distinguishing one 
record from another one. The record also contains one or more 

5 

SUBSTITUTE SHEET (RULE 26) 



99441 62A1_I_> 



WO 99/44162 



PCT/CA98/01198 



pointers, where these pointers use the URL addressing system in 
order to point to remote sites holding files that contain 
information in digitized form pertinent to the individual. That 
information may be blood tests , electrocardiograms among many other 
5 possibilities. Each pointer provides an address that is machine 
readable to import the data residing at the target location. 
Associated directly with the pointer is a data field, possibly 
stored in a mapping table in the memory of the NDSMR server, where 
this data field contains data indicative of the basic nature of the 
10 information held in the file or resource to which the pointer is 
directed. For the purposes of this specification, the term 
"associated" implies that the data field is either in a direct one- 
to-one mapping relationship with the pointer or, alternatively, is 
integrated with the pointer address to form the actual pointer data 
15 structure. Each record may also contain a collection of data 
elements which provide medical information that is intended to be 
stored in the record for easy retrieval. This information is 
typically data that is not likely to change during the lifetime of 
the individual. In a specific example, the data can include, among 
20 others, biological data pertinent to the individual, for instance 
blood type. 

In use, the database can be remotely queried to extract the 
record associated with a certain individual. Typically, this 
operation can be performed over a network, where a client 
25 workstation requests the record from a server managing the 
database. The server will transfer over the network links the 
record that will be displayed on the client workstation. The 
information displayed includes the collection of data elements 
permitting to identify the person, as well as any medical data 
30 stored in the record, where this data is more or less of a static 
nature. The operator at the workstation, typically a physician, 
will also observe one or more pointers to files holding additional 
medical data. The second part of each pointer, the data part, 
indicates to the physician the basic nature of the data pointed to. 
35 He can therefore select the pointers of interest in the global set 
of pointers for that record and import the data through any 
appropriate data transfer protocol. 
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This arrangement allows the establishment of an electronic ' 
medical file system of distributed nature where the bulk of the 
data is held at sites remote from the central database. Those 
remote sites are typically the locations where the data would be 
collected, such as hospitals. Accordingly, the system is very 
flexible as the records can be maintained even when a patient seeks 
medical attention and treatment at different sites. Take the 
example of a patient that visits Hospital A where an 
electrocardiogram is taken. The electrocardiogram is digitized, 
by simple optical scanning, and a file created in a local network 
of Hospital A. An archivist then accesses the remote database and 
adds a new pointer entry to the patient's record. If, at a later 
date, the patient visits another hospital, say Hospital B, for the 
same procedure, another file is created and the appropriate entry 
made in the patient's database record. Thus, the bulk of the 
medical data is retained in various locations, yet it can be easily 
accessed through the pointers' structure. 

Although the invention is better suited for applications where 
the medical records of patients are held in a database, the same 
inventive principles can also be used for applications where a 
single record is stored in the machine readable storage medium. 
Such a storage medium could be a portable memory device, of the so 
called "Smart Card" type. The portable memory device includes a 
single record, however, the data structure is the same, namely a 
collection of data elements of static, medical nature and at least 
one pointer toward a location containing additional medical 
information. To use such a portable memory device, it suffices to 
provide a suitable reader to extract the information contained 
therein and then to process the information accordingly, such as 
by remotely accessing and importing the data pointed to by the 
pointer ( s ) . 

As embodied and broadly described herein, the invention also 
provides a network server, including: 

- a processor; 

- a memory including: 
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10 



15 



a) a plurality of records associated with respective 
individuals, said record including: 

i) at least one unique identifier associated 
strictly with the respective individual; 

ii) at least one pointer, said pointer using 
the URL addressing system to indicate the 
address of a location containing data for 
the certain individual, said address 
being in a form such that a machine can 
access the location and import the data 
from the location; 

iii) at least one data field, said data field 
associated with said pointer, said data 
field being indicative of the basic 
nature of the data at the location 
pointed to by the said pointer. 



b) a program element including individual 
instructions, said program element implementing a 
functional block comprising means responsive to a 

20 request to transfer a particular record of said 

plurality of records towards a client connected to 
said server through a data communication pathway 
for locating the particular record and transferring 
the record toward the client over the data 

25 communication pathway. 

As embodied and broadly described herein, the invention also 
provides a network system for distributed storage of records, said 
network system including: 

- a server managing a database, said database containing a 
30 plurality of records of respective individuals, each record 



including 
a) 



at least one unique identifier associated strictly with 
the respective individual ; 



b) at least one pointer, said pointer using the URL 
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addressing system to indicate the address of a location, 
containing data for the certain individual, said address 
being in a form such that a machine can access the 
location and import the data from the location; 

5 c) at least one data field, said data field associated with 

said pointer, said data field being indicative of the 
basic nature of the data at the location pointed to by 
the said pointer. 

- a plurality of nodes remote from said server, said nodes 
10 being connected to said server through data communication pathways, 
said nodes constituting locations pointed to by pointers in records 
of said database and including machine readable storage media 
holding the data pointed to by pointers in record of said database. 

15 Brief Description of the Drawings 

Figure 1 is a block diagram of a generic client-server 
environment, where clients and server are linked by a local area 
network (LAN) ; 

Figure 2 is a flowchart which describes the current diagnostic 
20 process that takes place in medical facilities; 

Figure 3 is a block diagram of the health inforoute integrated 
with the Network Distributed Shared Medical Record (NDSMR) System, 
in accordance with the invention; 

Figure 4 is a flowchart which describes the diagnostic process 
25 which will take place in medical facilities under the NDSMR System; 

Figure 5 is a block diagram of a general client-server 
architecture ; 

Figures 6A, 6B and 6C represent the NDSMR document layout in 
accordance with a particular embodiment of this invention; 

30 Figure 7 is a block diagram of a server in accordance with 

this invention; 

Figure 8 is a flowchart of the program element in accordance 
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with this invention; 

Figure 9 is a flowchart of the update process performed by the 
archivists on the NDSMRs , in accordance with this invention; 

Figure 10 is a block diagram of the search engine (query) 
5 process implemented by the NDSMR system. 

Description of a Preferred Embodiment 

Figure 1 illustrates a generic client-server environment, 
enabled by a local area network (LAN) . Client-server computing is 

10 a cooperative relationship between one or more clients and one or 
more servers. The clients 104, 106, 108 and 110 submit requests 
to the server 102, which processes the requests and returns the 
results zo the clients. Although the processing is initiated by 
the client (s), both client (s) and server cooperate to successfully 

15 execute an application. Therefore, the interaction between the 
client and the server processes is a transactional exchange in 
which the client is proactive and the server is reactive. In 
addition to clients and server, the third essential component of 
the client -server environment is the network. Client-server 

20 computing is distributed computing. In other words, users, 
applications, and resources are distributed in response to business 
requirements and are linked by a single LAN 100 or by an Internet 
of networks . 

Currently, most medical facility archives still operate on a 
25 paper based support system. However, the higher end medical 
facilities are set up with their own LAN for archiving medical 
files, and the computing system is often modeled after the client- 
server system shown in Figure 1. Since each separate facility has 
its own LAN for archiving files, the accessibility to files of a 
30 particular LAN is limited to the workstations linked to that 
particular LAN . Figure 2 depicts an example of the current state 
of affaires faced by medical facilities. Assume an ambulance 
delivers an unconscious patient to the ER at step 200. At step 
202, the doctor makes an initial diagnosis, but needs access to the 
35 patient's medical history in order to prevent any misdiagnosis. 
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If the patient is without identification of any kind, the doctor 
has no other recourse but to administer a treatment at step 208 
based on a diagnosis that is potentially inaccurate because it has 
been established strictly on the patient's current medical 

5 condition, without taking into account his/her previous medical 
history. If the patient does have an identification of some kind, 
it can be used to cross-reference all of the hospital's medical 
files, archived locally and/or at assigned external archives, at 
step 206. The patient's file will only be found if the patient was 

10 previously treated at the same hospital and already has a file 
stored in the network server's database. If the file is not found, 
the doctor is back to step 208. Even if the file is found, it is 
often incomplete and inaccurate as it lacks the information 
concerning treatment (s) administered in other medical facilities. 

15 Therefore, at step 212 the doctor must make a final diagnosis and 
perform the corresponding treatment. 

Figure 3 depicts an integrated health network embodying the 
principles of this invention. For the purposes of this 

specification, the word "integrated" implies the implementation of 

20 internetwork communication between all of the various medical 
facility LANs, as well as with external sources such as the global 
Internet, the pharmaceutical network, on-line medical libraries and 
journals, among many other possibilities. An important component 
of this network is a Network Distributed Shared Medical Record 

25 (NDSMR) system that includes two main components, a server 300 and 
a NDSMR database 302, with the potential for each LAN within the 
health network to be connected to the server 300. Alternatively, 
the system may include more than one server, all operating inter- 
cooperatively in order to manage the NDSMR database, a resource 

30 shared by all of the servers. Although such integrated medical 
networks may be restricted to a particular geographical region, due 
to differing medical jurisdictions within a country or between 
different countries, it is an integration hurdle which could 
eventually be overcome as a result of a concept of the current 

35 invention known as an individual's biological signature, to be 
described in detail below. The integration of medical facilities 
could thus someday be national wide, or even international wide, 
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thereby enlarging and improving the health network. 

Figure 4 is a flowchart depicting the improved diagnosis 
process as a result of the present invention. Assume that an 
ambulance delivers an unconscious patient to Hospital A. Also 
5 assume that the patient is a network user of the health network, 
and therefore has a personal file stored in the NDSMR database. 
After the doctor makes his initial diagnosis at step 402, the 
patient is checked for identification. 

If the patient does have identification, his/her network 

10 validated or attributed identifier will be known at step 408. In 
the most preferred embodiment of this invention, such an identifier 
consists of the patient's medical insurance number such as the one 
available in a number of countries of the world, including Canada. 
Alternatively, the identifier may consist of the patient's social 

15 insurance number, Smart Card, or any other network attributed 
identification. A Smart Card is an integrated circuit based card 
containing individual specific medical information, to be read from 
and written to by appropriate electronic means, and offers several 
implementation alternatives to the NDSMR system, to be described 

20 in more detail below. If the patient does not have identification, 
his/her biological signature can be obtained as a universal 
identifier at step 406. In the most preferred embodiment of this 
invention, such an identifier consists of a fingerprint derived 
signature. The technology needed for the implementation of system 

25 user identification via a fingerprint derived biological signature 
could be software similar to that created by and available from 
delSecur, a Montreal based company. Alternatively, the identifier 
may consist of a patient's retinal or genetic derived signature, 
or any other type of biological signature. 

30 At step 410 the doctor sits down at workstation 3 04 and logs 

onto the server 300, as will be discussed below. When prompted, 
the doctor uses the identifier obtained at either step 406 or step 
408 in order to request the patient's NDSMR from the server 300. 
The record is transmitted from the NDSMR database 302 to the 

35 doctor's workstation. Once the doctor has read the pertinent 
medical information found in the record, he/she can scan a list of 
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pointers appended to the record. As will be further described 
below, these pointers represent various significant medical 
documents (such as x-rays, surgical reports, etc.), and by their 
textual or visual representation allow the doctor to determine 

5 which of the pointers refer to documents pertinent to the patient's 
current medical condition. Specific to this example, the doctor 
decides at step 414 that a pointer referring to the most recent 
electrocardiogram taken at Hospital B would be helpful for 
diagnosis, and at step 416 he/she activates the corresponding 

10 pointer. Consequently, the document is downloaded over the health 
network from Hospital B's LAN to the doctor's workstation. 

Figure 5 is a general representation of the client-server 
architecture that implements the NDSMR system. The system includes 
three main components, notably the client 304, the server 3 00 and 

15 the NDSMR database 302. In both client 304 and server 300, the 
basic software is an operating system running on the hardware 
platform. The platforms and the operating systems of the client 
and server may differ. Indeed, a key component of the NDSMR system 
is that through client-server computing a multitude of different 

20 types of operating systems may exist within the various medical 
facility LANs. As long as the client 304 and server 300 share 

the same communication exchange protocols and support the same 
applications, the lower-level differences are irrelevant. It is 
the communications software which enables clients and server to 

25 interoperate . Specific to the NDSMR system, the communication 
exchange protocol adopted will be an open, non-proprietary 
protocol, for instance the Internet Protocol, a standard exchange 
protocol in client-server networking, or any other similar 
progressive communication exchange protocol. 

30 For the purpose of this specification, the term interoperate 

implies, among other things, the ability of different system users 
(clients) to share server information and have on-line 
consultations, in both real and delayed time. Real-time computing 
is defined as the type of computing in which the correctness of the 

35 system depends not only on the logical result of the computation 
but also on the time at which the results are produced. Real-time 
tasks therefore attempt to control or react to events that take 
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place in the outside world. As these events occur in "real time", 
a real-time task must be able to keep up with the events with which 
it is concerned. On the other hand, delayed- time tasks are not at 
all concerned with the outside world events, delayed-time system 
correctness depending solely on the logical result of the 
computation. The benefits of real-time medical consultations in 
the case of emergencies are very obvious. Take for example a 
doctor at Hospital C conferring with a doctor at Hospital D that 
is remote from Hospital C. Both doctor's can share access to an 
individual's NDSMR, simultaneously studying the record, visible on 
both of their workstations, and communicating in real-time with 
each other via some sort of text, voice or video communications 
link, for instance an Internet messaging window, from their 
workstations. The equipment necessary to allow for such real-time 
communication will not be described in detail, as there are a 
variety of products available on the market that could be used for 
this task and that are well-known to persons skilled in the art. 

The server 3 00 is responsible for maintaining the NDSMR 
database, for which purpose a database management system module is 
required- A variety of different applications that make use of the 
database may be housed on the client machines . The operative 
relationship that ties clients, such as client 304, and server 300 
together is software that enables a client to make requests to the 
server 300 for access to the NDSMR database 302. It is important 
to note that the division of work between a client 3 04 and server 
300 may be allocated in a number of ways. In a preferred 
embodiment of this invention, the system implements cooperative 
processing, whereby the application processing is performed in an 
optimized manner by taking advantage of the strengths of both 
client and server machines and of the distribution of data. 
Although such a configuration is quite complex to set up and 
maintain, in the long run this configuration offers greater user 
productivity gains and greater network efficiency. Alternatively, 
the system may be. implemented with server-based processing or 
client-based processing. In server-based processing, the most 
basic class of client-server configuration, the client is mainly 
responsible for providing a user-friendly interface, whereas nearly 
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all of the processing is done on the server. In client-server 
processing, virtually all of the application processing is done at 
the client, with the exception of certain data validation routines 
and other database logic functions that are best performed at the 
5 server. This latter architecture is perhaps the most common 
client-server approach in current use. In the interest of clarity, 
the server-based processing implementation is described in the 
remainder of this description; however, the NDSMR client-server 
division of work may be any one of the options described above. 

10 Figure 7 is a more detailed block diagram of a preferred 

embodiment of the server 300, which has the responsibility of 
managing, sorting and searching the NDSMR database 3 02. Towards 
this end, the server is provided with a memory 720, high-speed 
processor/controllers 708, 710 and 712 {assume for this example 

15 that there are three) , and a high-speed input /output (I/O) 
architecture. The I/O architecture consists of the interfaces 702, 
704 and 706. An internal system bus 711 interconnects these 
components, enabling data and control signals to be exchanged 
between them. The server has 6 ports, identified as port A, port 

20 B, port C, port D, port E and port F . These ports connect the 
server to physical links 1, 2 and 3, allowing data to be 
transported to and from various clients within the network. In the 
example shown, ports A, B and C are input ports on the physical 
links 1, 2 and 3, respectively, while ports D, E and F are the 

25 output ports on those same physical links. The input ports are 
designed to receive data from their associated physical links, 
while the output ports are designed to transmit data over their 
associated physical links. 

The interfaces 702, 704 and 706 interconnect various input and 
30 output ports to the physical links 1, 2 and 3, respectively. Their 
function is to transmit incoming data packets to the internal 
system bus 711 for transport to the memory 72 0 where they can be 
processed by one of the processors. On the output side, the 
interfaces are designed to accept data packets from the' system bus 
35 711 and impress the necessary electrical signals over the 
respective physical links so that the signal transmission can take 
effect . It is not deemed necessary to discuss this standard 
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operation of the interfaces 702, 704 and 706 in more detail because 
it is well known to those skilled in the art and is not critical 
to the success of the invention. 

. The memory 720 contains a program element that controls the 
5 operation of the server. That program element is comprised of 
individual instructions that are executed by the controllers, as 
will be described in detail below. The program element includes 
several functional blocks that manage several tasks. One of those 
functional elements is the Database Management System (DBMS) 714 
10 which provides efficient and effective use and maintenance of the 
NDSMR database 302. The DBMS will not be described in detail 
because it is well known to those skilled in the technological 
field to which the present invention belongs. 

Besides the program element, the memory also holds the usual 
15 routing table that maps the destination addresses of incoming IP 
data packets (inherent to the IP communications exchange protocol) 
to the server output ports. It is not deemed necessary to discuss 
the structure of the routing table here because this component is 
not critical for the success of the invention and also it would be 
20 well known to a person skilled in the technological field to which 
the present invention belongs. The memory also provides random 
access storage, capable of holding data elements such as data 
packets that the processors manipulate during the execution of the 
program element . 

25 Another component stored in the memory 72 0 is a validation 

table, which maps all of the registered user IDs to a corresponding 
passwords . The table is used to validate clients logging on to the 
server, for security purposes. One of the characteristics of 
cooperative or client-based processing is that a system feature 

30 such as user validation would not necessarily be exclusive to the 
server, but could also take place, in whole or in part, at the 
client workstation. This would remove from the server a part or 
all of the burden of dealing with invalid clients, thus increasing 
system speed and efficiency. The identification table associates 

35 with each user a unique user profile that specifies . permissible 
operations and NDSMR accesses, in order to limit access to data 
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held within the database. Specifically, the table is used to 
identify between clients with different user privileges, for 
instance clients with archivist status as opposed to basic user 
status. Archivist status accords the client with read and write 

5 status, including editing and modifying privileges, for updating 
the NDSMRs. User status limits the client to NDSMR read status 
only. Finally the memory 72 0 contains a request queue which is a 
buffer memory space of the FIFO type, although alternative types 
of buffer memory space may also be used, that can hold data packets 

10 to be sent to one of the controllers for processing. The physical 
configuration of the buffer does not need to be described in detail 
because such a component is readily available in the marketplace 
and the selection of the appropriate buffer mechanism suitable for 
use in the present invention is well within the reach of a person 

15 skilled in the art. 

In a most preferred embodiment of this invention,- the NDSMR 
database 302 is part of the memory 720 of the server 300, as shown 
in Figure 7. In this embodiment, the NDSMR database 302 is 
actually on a separate storage medium, such as a non-volatile 

20 medium interconnected through a high speed data bus with the memory 
720 so the record set from the database 3 02 can be quickly loaded 
in the random access memory 720 for processing. Alternatively, the 
collection of data which makes up the NDSMR database 3 02 may be 
stored remotely on one or a set of physical storage device (s), for 

25 instance a disk. In such a case, one of the server's device 
drivers would be responsible for communicating directly with the 
peripheral device (s) in order to access the database. 

Figure 8 provides a complete flowchart illustrating an example 
of the operation of the program element stored in the memory 720, 

30 and executed by any one of the processor /controllers , that 
regulates the operation of the server 300, specifically its 
interaction with the clients as well as with the NDSMR database 
302. Although the server program is running at all times, if no 
clients are logged on to the server then it is in an effective 

35 perpetual wait state, shown at step 800. Once a client attempts 
to log on, control is passed to the validation functional bloc that 
is part of the program element in order to ensure that the client 
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is a server registered user at step 804. Validation consists 
simply in ensuring that the user's ID is known to the system 
(exists within the validation table) and that the user knows the 
correct password associated by the system with that ID (mapped by 

5 the validation table). If either the user's ID is not known to the 
system, or the password given is incorrect, validation will fail 
and the user refused possibility of logging on to the server. This 
is a basic validation procedure that is widely used. Evidently, 
more complex validation methods can be implemented, if the level 

10 of security demands it. Next, the server waits for a request from 
any of the logged on clients at step 806. When a request does 
occur, it arrives as a flow of data packets at interface 702, 704 
or 7 06, over physical link 1 , 2 or 3 , respectively. At step 810, 
the request is stored in the request queue found in memory 720, to 

15 await its turn for processing. The program element next releases 
a request from the queue (the oldest request) to any non-busy 
processor. If all of the processors are occupied, the release step 
is held-up until such a time where any of the three processors is 
available . 

20 Once a request has been released to a processor, the program 

element reaches step 814, whereby the requesting client is 
identified by the identification logic stored in memory 72 0. The 
identification logic first reads the request data packet header in 
order to determine the destination address for the response to the 

25 request, specifically the address of the requesting client which 
is read from the source field, and second assigns correct status 
to the client (user, archivist or other status) . This status is 
determined by the user profile, read from the identification table 
stored in memory 720. Step 814 also includes routing logic, 

30 whereby the routing table is accessed in the memory 720 in order 
to determine the correct output port for transmitting a database 
response to the particular client. 

At step 816, the processor must determine the search 
parameters specified by the request. These, parameters consist in 
35 a patient's identifier and/or a list of other qualifiers (for 
instance a particular treatment, medical condition, age group, sex, 
etc) . Control is passed to the DBMS logic at step 818, at which 
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point the search is performed on the NDSMR database. The DBMS not 
only performs the search on all data contained within the NDSMR 
database, but also controls access to specific records or even 
portions of records within the database, ensuring that confidential 
5 data or specific confidential parts of the data being accessed is 
masked when returned to the client, based on the user profile 
determined at step 814. The data returned by the NDSMR database 
search is transmitted over the pre-determined output port and to 
the appropriate client at step 820. 

10 As indicated above, an aspect of the current invention is the 

user- friendly interface provided at the client workstation 3 04. 
This interface facilitates the user's attempts at making requests 
of the server, through easy to follow prompts and an on-line 
knowledge system to help the user with any questions or problems. 
15 The interface allows the user to perform searches or queries on the 
NDSMR database, using information filters to simplify the 
extraction of pertinent data from what may be hundreds of thousands 
of network distributed shared medical records. The interface also 
allows the user to perform keyword-based Internet-wide searches, 
20 transparent to the user. For example, a workstation user could 
initiate an Internet search for all documents relating to a 
particular medical condition by simply inputting the name of the 
medical condition as the keyword, the search results returned to 
the user being a list of hypertext links to all corresponding 
25 Internet documents . The software used to implement this 

interface feature has been previously created .by the University of 
Quebec at Montreal (UQAM) , and is marketed under the name of 
Manitou or SV3 . Finally, the interface offers text processing 
tools, necessary to the editing, publication and merging of all 
30 data received from both the Internet and the server 300. Future 
variations to the NDSMR system may include a more progressive 
interface at the client workstation. Specifically, a three- 
dimensional view of the human body may be available to doctors and 
consultants logged on to the NDSMR server, used for making 
35 requests, medical enquiries and searches. 

The Network Distributed Shared Medical Record itself is 
another element. The NDSMR is an evolving summary medical document 
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for a particular individual, integrated in the form of a network' 
accessible document. By "summary", this implies that the record 
does not necessarily contain all the information currently found 
in local network medical archives. Rather it is a compendium of 
5 critical medical information pertinent to a particular individual, 
potentially useful in the medical diagnosis of an individual's 
state of health and corresponding treatment. The NDSMR is 
therefore a shared minimal record, offering a common communication 
interface to medical facilities that may be using incompatible 
10 information systems. It has the merit of being able to be 
consulted easily, at a distance, on an emergency basis, as opposed 
to the current situation of files archived in a local network but 
inaccessible to any users in other networks. 

In a preferred embodiment of this invention, the NDSMR 
15 includes at least one universal or network attributed identifier, 
distinguishing one record from another, and a dynamically updated 
list of biological data pertinent to the individual, accessible by 
pointers referring to the local network where the data is actually 
being stored. This biological data consists of significant medical 
20 documents in an electronic format such as laboratory tests, x-rays, 
surgical reports, electrographic data, etc. Alternatively, other 
embodiments of the NDSMR may also include a variety of other 
medical information pertinent to the individual. Figures 6A, 6B 
and 6C display a possible layout for the NDSMR as a WWW document, 
25 presenting several categories of medical information pertinent to 
an individual, in this example John Doe. The individual's 
identifier is indicated at the top of the record, as seen in Figure 
6A. Figures 6B and 6C display other categories of information, 
including: 

30 • administrative medical data (date of birth, home and work 
address and phone number, emergency contact, regular 
physician, etc) ; 

• permanent biological data (blood type, genetic markings or 
deficiencies, tissue antigens, etc) ; 

35 • significant antecedents (family medical history, personal 
medical history, surgical history, etc); 
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• current medical condition (allergies, medication, etc) . 

The final category seen in Figure 6C consists of the dynamically 
updated links to other biological data. The eight pointers listed 
refer to other medical documents pertinent to John Doe which are 
maintained in different local networks, and which can be downloaded 
from another network site to the client workstation by invoking the 
downloading operation embedded in the pointer, thus specifying the 
address of the site (and if necessary of a particular file at that 
site) . 

In addition to the set of pointers, the NDSMR could also offer 
access to complementary external sources of information, 
transparent to the workstation client. Potential sources could be 
pharmacy networks, medical libraries or journals, accessible to the 
doctor or consultant via references within the NDSMR seen on their 
workstation. Assume a consultant has downloaded John Doe's NDSMR 
from the server 3 00, and is verifying the Medication ( s ) Used 
reference under the Current Medical Condition category, seen in 
Figures 6C. When the consultant invokes the Medication (s ) Used 
reference, for instance by clicking with the computer mouse on the 
hypertext link, the NDSMR system will automatically generate user 
authorization in order to access an Internet published Medical 
Library that may be held on an Internet site containing this 
information, thus allowing the consultant to look up the specifics 
concerning John Doe's current medication. 

In accordance with this invention, the data structure of the 
pointer allows the workstation user, such as a doctor or 
consultant, to determine the general nature of the information to 
which the pointer is referring. In other words, the doctor can 
tell by simply looking at the pointer whether it points to a 
medical document concerning a pulmonary • x-ray, an 
electrocardiogram, allergy tests, etc. In a preferred embodiment 
of this invention, the pointer representation, as seen on the 
screen of the client workstation, is as seen in Figure 6C . The 
textual representation of the pointer indicates clearly to the user 
the medical document or information to which the pointer points, 
whether it be the most recent or a previous electrocardiogram, 
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coronarography, x-ray or brain CT scan. Alternatively, the 
pointers may be of a graphical representation, small icons used to 
specify relevant body parts and illustrate medical treatments. The 
scope of this invention also includes all other variations of a 

5 pointer representation implementation which reveals the nature of 
the information to which it points. Transparent to the user is the 
actual address, hidden beneath the physical representation, which 
is the actual device needed for contacting and downloading from 
various external LANs and other sources, to be discussed in more 

10 detail below. 

In short, the NDSMR record is data structure that contains two 
types of elements, namely a collection of medical data elements 
about the individual and one or more pointers that allow additional 
information to be downloaded, this additional information being of 

15 a medical nature and complementing the data held in the collection 
of medical data elements. Specific to this invention, these 
pointers adopt the URL (Universal Resource Locator) addressing 
system, allowing to point to a specific file in a directory, where 
that file and that directory can exist on any machine on the 

20 integrated health network and can be served via any of several 
different methods, specifically the Internet technologies such as 
ftp, http, gopher, etc. The URL addressing system is well 
documented and very well known to those skilled in the art, and 
therefore will not be described in more detail. 

25 Each pointer provides an address which may consist in the 

entire address information of the file pointed to by the pointer 
or in a reference to the address information, where the reference 
may be an index in a table that contains the address information. 
Associated directly with the pointer is a data field, possibly 

30 stored in a mapping table in the memory of the NDSMR server, where 
this data field contains data indicative of the basic nature of the 
information held in the file or resource to which the pointer is 
directed. For the purposes of this specification, the term 
"associated" implies that the data field is either in a direct one- 

35 to-one mapping relationship with the pointer or, alternatively, is 
integrated with the pointer address to form the actual pointer data 
structure. In a very specific embodiment, the data field 
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associated with the pointer, indicative of the basic nature of the 
information pointed to, can contain codes normally used by 
physicians to categorise treatment events that they have 
administered to patients. Those codes are normally used for 
remuneration purposes, however, they can be employed here in a 
satisfactory manner as indicators of the nature of the medical 
data. Alternatively, the data field associated with the pointer 
may also contain the date and time at which the pointer was created 
(enabling the display of the information at the client workstation 
to be effected in a chronological order) , a textual description of 
the medical information pointed to, a brief description of the 
status /results of the medical information pointed to, etc. 

To facilitate the reading of the information associated with 
the pointers, namely the basic nature of the medical data, the 
display of the pointers may be organized and enhanced to enable the 
user to easily grasp the meaning of the data without the necessity 
to refer to lists cross-referencing codes with the basic nature of 
the medical data. This can be accomplished in several ways. For 
instance, the pointers related to the same information, for 
instance containing the address of files that hold 
electrocardiograms, may be displayed on the client workstation in 
a separate window and arranged in that window in chronological 
order. Another possibility is to display besides each pointer an 
icon or text box with the suitable data. This can be accomplished 
by providing the clients workstation with a table that maps the 
code in the pointer identifying the basic nature of the medical 
data with the type of information to be displayed to the user. 
When the NDSMR is loaded from the remote server 300, the list of 
pointers is identified and scanned to extract from them the codes 
identifying the basic nature of the medical data. The codes are 
then cross-referenced through the table with the corresponding 
information to be displayed. The information is then displayed on 
the screen of the user. 

Another aspect of this invention is the update of the NDSMRs , 
following the creation of new medical data. This task could be 
effected by a NDSMR administrator, be it a medical archivist, 
webmaster or some other administrative appointee, also responsible 
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for the maintenance and regular update of a local medical 
information system. Taking for example the medical archivist, it 
is known that within all of the healthcare establishments such 
archivists are currently responsible for ensuring a good upkeep of 

5 all local medical files, as well as for producing hospitalization 
summaries, and therefore are aware of all recent medical acts and 
treatments performed within their medical facility. An alternative 
to the use of NDSMR administrators is the implementation of 
automatic NDSMR updates, a process which would involve the 

10 incorporation of some sort of intelligence system into all local 
medical network information systems. 

Figure 9 illustrates an example of a procedure to be followed 
by medical facility archivists in order to update the NDSMRs . 
Assume that the archivist within a particular medical facility 
15 receives on a regular basis a list of recent medical acts performed 
at the facility, as well as supporting documents for these acts. 
At step 902, the archivist updates the facility's local Intranet 
medical files and creates updated hospitalization summaries . The 
archivist's next step is to log on to the NDSMR server, using an 
20 archivist assigned password, at step 904. The server and its DBMS 
will recognize the archivist password and profile and assign 
privileges accordingly, as described above for steps 804 and 818 
of the NDSMR server program element. For each different patient 
appearing on the archivist's updated list, a recjuest must be made 
25 in order to retrieve the appropriate NDSMR. The request is made 
on the basis of the particular patient's identifier, submitted to 
the NDSMR server at step 906. At step 908, the NDSMR is downloaded 
to the archivist's workstation, at which point the archivist is 
capable of modifying and updating certain sections of the data 
30 contained in the NDSMR, for instance the Significant Antecedents, 
Current Medical Condition and Links To Other Biological Data 
categories as seen in Figure 6C . At step 910, the archivist refers 
to the updated list to update the NDSMR in order to reflect the 
individual's most recent and pertinent medical information, 
35 treatments and corresponding pointers. For example, assume that 
one of the archivist's list entries is that Mr. John Doe has 
undergone a new electrocardiogram at Hospital E. The archivist 
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will then change the Most Recent Electrocardiogram reference seen 
in the Links To Other Biological Data category of Mr. Doe's NDSMR 
to point to the Hospital E local network, more particularly to the 
file containing the digitized electrocardiogram. 

5 It is important to note that in order for the NDSMR system to 

function within an extended network of LANs or local Intranets, all 
documents referred to by pointers should be archived according to 
a specific nomenclature and be accessible outside of the LAN. In 
a most preferred embodiment of this invention, this specific 
10 nomenclature consists of that adopted by a state or national 
medical insurance company, thus ensuring record consistency and 
successful searches. The pointer addresses, transparent to the 
user, must also have a specific structure, to be respected by all 
archivists. In a most preferred embodiment of this invention, the 
15 structure of the pointer addresses, all the while respecting the 
URL addressing system, consists in a combination of a local network 
and machine address (or domain name), a patient's identifier, and 
a code taken from a published manual of medical act codes adopted 
by a state or national medical insurance company. There do exist 
20 alternatives to the specific nomenclature and pointer structure 
used by the NDSMR system, and the scope of this invention includes 
all other such variations whereby consistency is assured within the 
system. 

Yet another feature of this invention is its use as a 
25 search/query engine. Not only can a user perform searches for or 
queries on NDSMRs within his/her own local Intranet, but also 
within external sources. NDSMR searches and queries may be 
performed on two different types of data, and therefore databases: 
nominative and non-nominative. Non-nominative medical data and 
30 databases are accessible to all authorized users, but do ' not 
require authorization from the patient whose personal data is being 
consulted. Nominative medical data and databases require search 
authorization from both the workstation client, typically a doctor 
or consultant, and the concerned patient, with the exception of 
35 situations where emergency medical care is required. The search 
requester will be prompted for this authorization through the 
workstation interface described above, the authorization comprising 
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some form of password, biological signature or smart card. In the 
case where a search is performed by a user without nominative 
search authorization, the NDSMR Database Management System (DBMS) 
will automatically mask any nominative data found in the database 

5 response before transmitting it to the client workstation. In 
summary, the NDSMR system permits the delay-free consultation of 
pertinent information found within different local files and, for 
authorized users, offers an integrated research motor which allows 
for non-nominative research, by object or by concept, on the whole 

10 of the accessible databases. 

Figure 10 displays the query usage allowed by the NDSMR 
system. From a client workstation, a user may make an initial 
query of the server 300. The server's DBMS and database logic 
allow the NDSMR database 302 to be searched rapidly and 

L5 efficiently. The database logic is what allows the server to not 
only retrieve records on behalf of the client but also to perform 
searches on behalf of the client. We see in Figure 10 that an 
initial query returned 300 possible NDSMRs . The system allows the 
user to send out a second, more narrow query, with a resulting 25 

20 NDSMRs returned. The system is therefore very efficient, 
especially for massive searches performed across all accessible 
databases. In a most preferred embodiment of this invention, the 
query style offered by the workstation interface will be one of 
relational data searches, such as the style currently offered by 

25 the Alta Vista (Trade mark) web browser. The query style will not 
be described in detail as it is very well known to a person skilled 
in the art. Alternatively, many other query styles could be 
incorporated into the NDSMR search engine, for instance an object- 
oriented search style. 

30 The structure of the pointers as described above, where both 

an address part and an associated data part form a pointer, allows 
the NDSMR system to perform searches on all of the pointers 
contained within the NDSMR database, representing medical files 
archived at all of the various local networks connected within the 

35 extended health network. As mentioned above, the data structure 
of the pointers allows the nature of the information to which they 
point to be determined, either directly from the data structure 
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itself in the case where both the data part and address part of the 
pointer are integrated to form the data structure of the pointer, 
or through a one-to-one mapping between the address part of the 
pointer's data structure and the data part, possibly stored in a 
mapping table in the memory of the NDSMR server. Consequently, 
medical searches performed on the NDSMRs will return all database 
records containing pertinent pointer links. These links will allow 
the user to research medical data from all over the health network, 
currently impossible but vital to progressive medical development. 
Thus a query could be made to extract records based on a key 
relating to the basic medical information. For example, one could 
extract the records of all individuals between the age of 25 - 3 5 
that have undergone a particular therapy. This information is 
particularly useful in statistical studies. 

As mentioned above, the use of a Smart Card as a unique 
network validated or attributed identifier for the NDSMR system 
users offers several implementation alternatives to the system. In 
a specific alternative embodiment of the invention, the Smart Card 
can be used at the client workstation in order to access the NDSMR 
database. For example, upon attempting to log onto the NDSMR 
system, the client, most likely a physician, will be prompted by 
the NDSMR system server (through the user- friendly interface seen 
at the workstation) to insert the patient's Smart Card into the 
workstation's appropriate electronic means. These electronic means 
read the information contained on the card and can extract the 
patient's identification. The NDSMR server's program element then 
passes control to its validation functional bloc in order to ensure 
that the patient is a server registered user, as described above. 
In another example, the NDSMR system server may prompt the client 
workstation user for two Smart Cards, both the physician's and the 
patient's, thereby increasing the security of the system. 

The Smart Card may provide more than simple user 
identification. In another alternative embodiment of the 

invention, a patient's Smart Card contains medical information 
specific to the patient. In one example, the NDSMR system includes 
the Smart Card as a storage medium for system user information, 
with the NDSMR database records consisting strictly in at least one 
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unique identifier and a dynamically updated list of pointers to 
relevant medical information located at remote locations. In such 
a system, the patient's Smart Card would contain all other medical 
information pertinent to the individual, for instance that shown 

5 in Figures 6A, 6B and 6C (minus the Links To Other Biological 
Data) . Upon logging in to the NDSMR system with a Smart Card (or 
two), the medical information stored on the patient's Smart Card 
would appear on the client workstation, along with the list of 
pointers downloaded from the patient's record in the NDSMR 

10 database. In another example, a patient's nominative information 
could all be stored on the Smart Card, with only the patient's non- 
nominative information stored in the NDSMR database along with the 
identifier (s) and the list of pointers. This particular 

implementation of the system would ensure that no queries /searches 

15 performed on the NDSMR database revealed any confidential, 
nominative patient information. 

A patient's Smart Card, or alternatively any other form of 
portable computer readable storage medium, may also be used to 
store and maintain all or a portion of the data found in the 
20 particular patient's NDSMR, where this data may be nominative, non- 
nominative, static or dynamic. In such a situation, the NDSMR 
server offers a continuously available means of update for the 
Smart Card, the update consisting in reading the latest information 
from the NDSMR and writing it to the Smart Card via the appropriate 

25 electronic means, without changing any of the static or nominative 
data stored on the card. This implementation would allow a 
physician, at a hospital external to the NDMSR system's integrated 
health network, to have access to the individual's pertinent and 
most recent medical information, the only requirement being that 

30 the hospital must have the appropriate electronic means to read the 
individual's Smart Card. A variety of other NDSMR system 
implementations also exist, distributing the whole of the patients' 
medical information between database records and patient Smart 
Cards or other such portable computer readable storage media, and 

35 are included within the scope of this invention. 

The above description of a preferred embodiment under the 
present invention should not be read in a limitative manner as 
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refinements and variations are possible without departing from the 
spirit of the invention. The scope of the invention. is defined in 
the appended claims and their equivalents . 
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X Claim: 

1. A computer readable storage medium holding a data structure, 
said data structure comprising at least one record associated 
with a certain individual, said record including: 

at least one unique identifier associated with the 
certain individual ; 

at least one pointer, said pointer using the URL 
addressing system to indicate the address of a 
location containing data for the certain 
individual, said address being in a form such that 
a machine can access the location and import the 
data from the location ; 

at least one data field, said data field associated 
with said pointer, said data field being indicative 
of the basic nature of the data at the location 
pointed to by the said pointer. 

2. A computer readable storage medium as defined in claim 1, 
wherein the pointer in said record points to medical data. 

3. A computer readable storage medium as defined in claim 2, 
wherein said record is a medical record for said certain 
individual . 

4. A computer readable storage medium as defined in claim 3, 
wherein said record includes a collection of data elements 
containing information of a medical nature for the certain 
individual . 

5. A computer readable storage medium as defined in claim 1, 
wherein said record includes a plurality of pointers, one of 
said plurality of pointers being indicative of an address of 
a first location, another one of said pointers being 
indicative of an address of a second location that is remote 
from the first location. 

6. A computer readable storage medium as defined in claim 5, 
wherein the first and the second locations are different nodes 
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in a network. 

A computer readable storage medium as defined in claim 6, 
comprising a multitude of records. 

A computer readable storage medium as defined in claim 7, 
wherein said computer readable storage medium resides on at 
least one server in a network. 

A computer readable storage medium as defined in claim 1, 
wherein said unique identifier is a derived biological 
signature of the certain individual. 

A network server, including: 

— a processor; 

- a memory including: 

a) a plurality of records associated with respective 
individuals, said record including: 

iv) at least one unique identifier associated 
with the respective individual; 

v) at least one pointer, said pointer using 
the URL addressing system to indicate the 
address of a location containing data for 
the certain individual, said address 
being in a form such that a machine can 
access the location and import the data 
from the location; 

vi) at least one data field, said data field 
associated with said pointer, said data 
field being indicative of the basic 
nature of the data at the location 
pointed to by the said pointer. 

b) a program element including individual 
instructions, said program element implementing a 
functional block comprising means responsive to a 
request to transfer a particular record of said 
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plurality of records towards a client connected tu 
said server through a data communication pathway 
for locating the particular record and transferring 
the record toward the client over the data 
communication pathway. 

A server as defined in claim 10, wherein the pointer in said 
record points to medical data. 

A server as defined in claim 11, wherein said record is a 
medical record for the respective individual . 

A server as defined in claim 12, wherein each record includes 
a collection of data elements containing information of a 
medical nature for the respective individual . 

A server as defined in claim 10, wherein each record includes 
a plurality of pointers, one of said plurality of pointers 
being indicative of an address of a first location, another 
one of said pointers being indicative of an address of a 
second location that is remote from the first location. 

A server as defined in claim 14, wherein the first and the 
second locations are different nodes in a network. 

A network system for distributed storage of records, said 
network system including: 

at least one server managing a database, said database 
containing a plurality of records of respective 
individuals, each record including: 

a) at least one unique identifier associated with 
the respective individual; 

k) at least one pointer, said pointer using the 
URL addressing system to indicate the address 
of a location containing data for the certain 
individual, said address being in a form such 
that a machine can access the location and 
import the data from the location; 

c) at least one data field, said data field 
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associated with said pointer, said data field 
being indicative of the basic nature of the 
data at the location pointed to by the said 
pointer. 

5 a plurality of nodes remote from said server, said nodes 

being connected to said server through data communication 
pathways, said nodes constituting locations pointed to 
by pointers in records of said database and including 
machine readable storage media holding the additional 

10 data pointed to by pointers in record of said database. 

17. A network system as defined in claim 16, wherein the pointer 
in said record points to medical data. 

18. A network system as defined in claim 17, wherein said record 
is a medical record for the respective individual. 

15 19. A network system as defined in claim 18, wherein each record 
includes a collection of data elements containing information 
of a medical nature for the respective individual. 

20. A network system as defined in claim 19, wherein each record 
includes a plurality of pointers, one of said plurality of 

20 pointers being indicative of an address of a first location, 

another one of said pointers being indicative of an address 
of a second location that is remote from the first location. 

21. A network system as defined in claim 16, wherein said network 
system includes a plurality of servers managing said database. 

25 22. A method for performing information queries within a network 
system, said network system including: 

at least one server managing a database, said database 
containing a plurality of records of respective 
individuals, each record including: 

30 a) at least one unique identifier associated with 

the respective individual; 

b) at least one pointer, said pointer using the 
URL addressing system to indicate the address 
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of a location containing data for the certain 
individual, said address being in a form such 
that a machine can access the location and 
import the data from the location; 

5 c) at least one data field, said data field 

associated with said pointer, said data field 
being indicative of the basic nature of the 
data at the location pointed to by the said 
pointer . 

10 - a plurality of nodes remote from said server, said nodes 

being connected to said server through data communication 
pathways, said nodes constituting locations pointed to 
by pointers in records of said database and including 
machine readable storage media holding the additional 

15 data pointed to by pointers in records of said database, 

said method comprising the step of processing the data 
fields associated with the pointers of said records to 
extract information. 

23. A method as defined in claim 22, wherein the pointer in said 
20 record points to medical data. 

24. A method as defined in claim 23, wherein said record is a 
medical record for the respective individual. 

25. A method as defined in claim 24, wherein each record includes 
a collection of data elements containing information of a 

25 medical nature for the certain individual . 

26. A method as defined in claim 25, wherein said method comprises 
the step of performing a search on all of the medical 
information included in the collection of data elements, for 
the plurality of medical records stored in the database. 

30 27. A method as defined in claim 26, wherein said method comprises 
the step of performing a search on all of the non-nominative 
medical information included in said collection of data 
elements, for the plurality of medical records stored in the 
database . 
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A method for updating a certain individual ' s computer readable 
storage medium with data held in a network server, said 
network system including: 

- a processor; 

- a memory including: 

a) a plurality of records associated with respective 
individuals , said record including : 

i. at least one unique identifier associated 
with the respective individual; 

ii. at least one pointer, said pointer using 
the URL addressing system to indicate the 
address of a location containing data for 
the respective individual, said address 
being in a form such that a machine can 
access the location and import the data 
from the location; 

iii. at least one data field, said data field 
associated with said pointer, said data 
field being indicative of the basic 
nature of the data at the location 
pointed to by the said pointer. 

b) a program element including individual 
instructions, said program element implementing a 
functional block comprising means responsive to a 
request to transfer a particular record of said 
plurality of records towards a client connected to 
said server through a data communication pathway 
for locating the particular record- and transferring 
the record toward the client over the data 
communication pathway. 

A method as defined in claim 28, wherein the pointer in said 
record points to medical data. 

A method as defined in claim 29, wherein said record is a 
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medical record for the respective individual. 

31. A method as defined in claim 28, wherein the computer readable 
storage medium contains a portion of the medical data stored 
in the record of the respective individual. 

5 32 . A method as defined in claim 28, wherein said computer 
readable storage medium is a Smart Card. 
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